12章 ユーザーストーリーの分割

リリース計画の上位に来ているストーリー (p.137)

IMO：ここのガイドラインを使ってさらに細かくできそう（9にあるようにこの本はあまり細かくしない立場）

1.ユーザーストーリーをいつ分割するのか

イテレーションに収まらない場合

大きすぎる

他のストーリーがあって組み入れると溢れてしまう

部分的にでも組み入れたい

より正確な見積りが必要な場合

プロダクトオーナーは、新機能に見合う価値があるかどうかをまず考える

大きなストーリーへの見積りをより正確にしたい場合

分割ガイドライン

2.データ境界に沿って分割する

3.操作の境界で分割する

4.横断的な関心事を分離する

5.パフォーマンス制約をストーリーにする

6.優先度に沿ってストーリーを分割する

7.ストーリーをタスクに分割してはならない

8.関連する変更への誘惑を断つ

9.ストーリーをまとめる

1つ1つは小さすぎるストーリーをまとめる

1つ1つ小さすぎる例：バグレポート

チームのイテレーションの期間が2週間なら、2日から5日で完了できる大きさにストーリーを分割するのが適切だ (p.144)

筆者（マイクさん）の主張としては、イテレーションが1週間なら1日から2.5日ということになりそう